Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support configuration reloads for logging #6720

Merged
merged 8 commits into from
Jun 1, 2016

Conversation

bevacqua
Copy link
Contributor

A fix for #4407. Users can reload configuration through the following command even if --no-watch is turned on.

kill -s SIGHUP `cat ./pid.log` # or wherever/whatever your pid may be

The even-better package is a fork of good that supports reloading configuration.

@bevacqua
Copy link
Contributor Author

It should be noted that several different approaches were considered, and this was by far the simplest. For completeness:

  • Considered going this route but initially passed on it
  • Considered turning app into a cluster (master/ couple workers, then the master gets SIGHUP and recycles workers in sliding window), didn't try this route
  • Attempted a couple of ideas from @spalger where we'd proxy the hapi server in a number of places, but this proved to be very tricky to implement and it touched in lots of places, so I abandoned it
  • Went back to first option, which is this PR

@@ -97,6 +97,7 @@
"d3": "3.5.6",
"elasticsearch": "10.1.2",
"elasticsearch-browser": "10.1.2",
"even-better": "7.0.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol ❤️

@spalger
Copy link
Contributor

spalger commented Apr 1, 2016

made some notes, but looks good otherwise!

@spalger spalger assigned bevacqua and unassigned spalger Apr 1, 2016
@bevacqua
Copy link
Contributor Author

bevacqua commented Apr 1, 2016

@spalger Are you still reviewing this or should I assign somebody else now that you've betrayed us?

@bevacqua bevacqua assigned spalger and unassigned bevacqua Apr 1, 2016
@spalger
Copy link
Contributor

spalger commented Apr 1, 2016

@bevacqua haha, yes.

@spalger
Copy link
Contributor

spalger commented Apr 5, 2016

Implementation looks great. Can you get write a couple high-level tests for this? I'm thinking it should probably use child processes which actually write to files and rotate from one file to another.

@spalger spalger assigned bevacqua and unassigned spalger Apr 5, 2016
@bevacqua
Copy link
Contributor Author

bevacqua commented Apr 5, 2016

Added a test case for this. Let me know if there's an alternative that's better than waiting for a fixed amount of seconds.

@bevacqua bevacqua assigned spalger and unassigned bevacqua Apr 5, 2016
server:
port: 8274
logging:
dest: src/cli/serve/__tests__/logs/first.log
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you set the cwd of the process you can move this into code (where it will be easier to keep up to date)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wat? Not sure how the cwd changes this at all, but I'm removing the log to file config in favor of what you mention in the next comment

@spalger
Copy link
Contributor

spalger commented Apr 5, 2016

jenkins, test it

@bevacqua
Copy link
Contributor Author

bevacqua commented Apr 6, 2016

@spalger Wrote a more precise test case

@bevacqua bevacqua assigned spalger and unassigned bevacqua May 24, 2016
@bevacqua
Copy link
Contributor Author

@spalger Test is now fixed

@spalger
Copy link
Contributor

spalger commented May 24, 2016

LGTM

@spalger spalger assigned bevacqua and unassigned spalger May 24, 2016
@bevacqua
Copy link
Contributor Author

@rashidkpc Maybe you want to give it the second pass?

@w33ble w33ble assigned w33ble and unassigned bevacqua May 26, 2016
@w33ble
Copy link
Contributor

w33ble commented May 26, 2016

This looks good, but I hit an issue that I've previously only seen in dev mode. Usually, if you save changes often, you get a warning in node about a possible EventEmitter leak; I generally ignore this as I figured it was caused by the watch process.

However, I'm seeing the same message here after I issue several SIGHUP's to the server.

From the stack trace it looks like it's coming from this PR, as it starts from process.on('SIGHUP'...

Repro: PID=1234; while [ 1 ]; do kill -s SIGHUP $PID; sleep 2; done, you'll see the error the 10th time it's called.

Maybe it's actually a bug in even-better?

(node) warning: possible EventEmitter memory leak detected. 11 request-internal listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at [object Object].addListener (events.js:239:17)
    at [object Object].internals.Kilt.on.internals.Kilt.addListener (/Users/d33t/repos/kibana/node_modules/hapi/node_modules/kilt/lib/index.js:66:45)
    at new module.exports.Monitor.internals.NetworkMonitor (/Users/d33t/repos/kibana/node_modules/even-better/lib/network.js:18:18)
    at setupOpsMonitoring (/Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:89:23)
    at /Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:156:47
    at done (/Users/d33t/repos/kibana/node_modules/even-better/node_modules/items/lib/index.js:30:25)
    at KbnLogger.init (/Users/d33t/repos/kibana/src/server/logging/log_reporter.js:32:5)
    at /Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:149:18
    at iterate (/Users/d33t/repos/kibana/node_modules/even-better/node_modules/items/lib/index.js:35:13)
    at Object.exports.serial (/Users/d33t/repos/kibana/node_modules/even-better/node_modules/items/lib/index.js:38:9)
    at [object Object].internals.Monitor.start (/Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:124:11)
    at [object Object].reconfigure (/Users/d33t/repos/kibana/node_modules/even-better/lib/index.js:20:17)
    at KbnServer.applyLoggingConfiguration (/Users/d33t/repos/kibana/src/server/kbn_server.js:122:48)
    at process.reloadConfig (/Users/d33t/repos/kibana/src/cli/serve/serve.js:160:17)
    at emitNone (events.js:67:13)
    at process.emit (events.js:166:7)
    at Signal.wrap.onsignal (node.js:804:46)
(node) warning: possible EventEmitter memory leak detected. 11 response listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at [object Object].addListener (events.js:239:17)
    at [object Object].internals.Kilt.on.internals.Kilt.addListener (/Users/d33t/repos/kibana/node_modules/hapi/node_modules/kilt/lib/index.js:66:45)
    at new module.exports.Monitor.internals.NetworkMonitor (/Users/d33t/repos/kibana/node_modules/even-better/lib/network.js:19:18)
    at setupOpsMonitoring (/Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:89:23)
    at /Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:156:47
    at done (/Users/d33t/repos/kibana/node_modules/even-better/node_modules/items/lib/index.js:30:25)
    at KbnLogger.init (/Users/d33t/repos/kibana/src/server/logging/log_reporter.js:32:5)
    at /Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:149:18
    at iterate (/Users/d33t/repos/kibana/node_modules/even-better/node_modules/items/lib/index.js:35:13)
    at Object.exports.serial (/Users/d33t/repos/kibana/node_modules/even-better/node_modules/items/lib/index.js:38:9)
    at [object Object].internals.Monitor.start (/Users/d33t/repos/kibana/node_modules/even-better/lib/monitor.js:124:11)
    at [object Object].reconfigure (/Users/d33t/repos/kibana/node_modules/even-better/lib/index.js:20:17)
    at KbnServer.applyLoggingConfiguration (/Users/d33t/repos/kibana/src/server/kbn_server.js:122:48)
    at process.reloadConfig (/Users/d33t/repos/kibana/src/cli/serve/serve.js:160:17)
    at emitNone (events.js:67:13)
    at process.emit (events.js:166:7)
    at Signal.wrap.onsignal (node.js:804:46)

@w33ble w33ble assigned bevacqua and unassigned w33ble May 26, 2016
@bevacqua
Copy link
Contributor Author

bevacqua commented Jun 1, 2016

@w33ble Fixed memory leak issues via [email protected] 1a1f679c

@bevacqua
Copy link
Contributor Author

bevacqua commented Jun 1, 2016

jenkins, test it

@bevacqua bevacqua assigned w33ble and unassigned bevacqua Jun 1, 2016
@bevacqua
Copy link
Contributor Author

bevacqua commented Jun 1, 2016

Passes 🎉 Re-running just in case

jenkins, test it

@w33ble
Copy link
Contributor

w33ble commented Jun 1, 2016

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants